2. Integrating ACS with a SAML Token Provider
In the previous example,
the web service consumer creates an SWT token with input claims locally
with the User and Administrator roles. But in real-world enterprise
applications, user authentication is typically provided by enterprise
identity providers like Active Directory. An Active Directory with an
ADFS v2.0 instance can create SAML tokens and input claims that can be
processed by ACS. ADFS v2.0 can be configured to be a trusted issuer of
tokens to ACS. The web service client then sends SAML token issued by
ADFS v2.0 instead of locally created SWT tokens. In this section, you
see an example of integrating ACS with ADFS v2.0 to protect a web
service. Figure 7 illustrates the architecture of integrating ACS with a SAML provider.
The overall architecture is
very similar to the previous example. The main difference is that the
input token to ACS is issued by ADFS v2.0 and is of type SAML instead
of SWT. In this section, you learn to modify a web service client to
obtain a SAML token from a SAML token provider and use it to request an
SWT token from ACS. You use the same relying party web service you used
in the previous example. This way, you see how ACS provides abstraction
between multiple token providers.
The following are the prerequisites for running the example in this section:
Download and
install all these prerequisites. The Identity Developer Training Kit
consists of some labs and sample code that I use in this example.
The steps for integrating ACS with a SAML token provider are outlined in the following sections.
NOTE
ADFS v2.0 is a SAML
token provider, but it requires you to install Active Directory and
other infrastructure components. With the WIF SDK, you can create your
own identity provider. This example uses the LocalSTS server, which is
available as part of the Introduction to Access Control lab in the
following folder:
C:\IdentityTrainingKit\Labs\IntroAccessControlService\Source\Ex02-UsingACSWithSAMLTokens\Assets.
